Python: Prevent divergence in type-hint analysis. (ODASA-8075)#1869
Merged
BekaValentine merged 4 commits intoSep 6, 2019
Conversation
Otherwise it'll keep timing out until the fix has been pushed to LGTM.com
Contributor
Author
|
As discussed, I've added a test case to show what happens when nested types are encountered. My main worry was that something like |
BekaValentine
approved these changes
Sep 6, 2019
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes an unfortunate (but highly specific) divergence in the points-to analysis.
The following piece of code is a (more or less) minimal example that exhibits the divergence:
The culprit is the support for subscripted types originally introduced in #1728. Essentially, given the above,
foo(the variable) can point to the subscripted typefoo[foo], but then also the subscripted type(foo[foo])[(foo[foo])and so on. Thankfully, only two projects on LGTM.com exhibited the above divergence.To fix this, we block the recursion by requiring that the two types involved in a type subscripting operation (
AandBinA[B]) must not themselves be subscripted types.As this fixes an (obscure) regression in the analysis, I don't think it needs a change note.
Performance comparison here: https://git.semmle.com/gist/taus/8c8f31f2bb72055e50cc97bcce070747
Looks like a ~30% increase in performance across the board. Also seems to remove a bunch of false positives.